home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group00a.txt
/
000040_icon-group-sender _Wed Mar 1 10:33:17 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2001-01-03
|
2KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA06889
for icon-group-addresses; Wed, 1 Mar 2000 10:31:31 -0700 (MST)
Message-Id: <200003011731.KAA06889@baskerville.CS.Arizona.EDU>
From: gep2@terabites.com
Date: Tue, 29 Feb 2000 18:31:14 -0600
Subject: Re: closing a closed file
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
>> The Icon book doesn't say what happens when you close a closed file, but
> some real applications assume that it is a no-op.
That makes sense. You close a file because you want it closed. If it's ALREADY
in that condition, you got what you wanted. No biggie.
> BTW IMHO file should not be closed more than one time ;-)
IMHO the system shouldn't care.
File handles, I believe, ought to behave like other Icon items. When you don't
need them anymore, you simply overwrite the file handle and the file gets
"garbage collected". (In that case, the ENTIRE close() routine becomes a
no-op).
Any files whose handles aren't closed before program exit ought to be closed
when the program exits.
I don't see a BIG problem with allowing an explicit close. But if you reopen an
existing file (and reuse a previously used handle) or close a file that's
already closed, or even just forget about closing one, the system shouldn't
really care.
Gordon Peterson
http://web2.airmail.net/gep2/
Support the Anti-SPAM Amendment! Join at http://www.cauce.org/
12/19/98: the day the Conservatives demonstrated their scorn for their
fraudulent sham of representative government. Voters, remember it!